Data has become an important asset in almost every application, whether it is a Line-of-Business (LOB) application utilized for browsing products and generating orders, or a Personal Information Management (PIM) application used for scheduling a meeting between people. Applications perform both data access/manipulation and data management operations on the application data. Typical application operations query a collection of data, fetch the result set, execute some application logic that changes the state of the data, and finally, persist the data to the storage medium.
Traditionally, client/server applications relegated the query and persistence actions to database management systems (DBMS), deployed in the data tier. If there is data-centric logic, it is coded as stored procedures in the database system. The database system operated on data in terms of tables and rows, and the application, in the application tier, operated on the data in terms of programming language objects (e.g. Classes and Structs). The mismatch in data manipulation services (and mechanisms) in the application and the data tiers was not tolerable in the client/server systems and is even more of a problem in relation to muli-tiered sytems with different types of data. However, with the advent of the web technology (and Service Oriented Architectures) and with wider acceptance of application servers, applications are becoming multi-tier, and more importantly, data is now present in every tier.
In such tiered application architectures, data is manipulated in multiple tiers. In addition, with hardware advances in addressability and large memories, more data is becoming memory resident. Applications are also dealing with different types of data such as objects, files, and XML (eXtensible Markup Language) data, for example.
In hardware and software environments, the need for rich data access and manipulation services well-integrated with the programming environments is increasing. One conventional implementation introduced to address the aforementioned problems is a data platform. The data platform provides a collection of services (mechanisms) for applications to access, manipulate, and manage data that is well integrated with the application programming environment. However, such conventional architecture falls short in many respects. Some key requirements for such a data platform include complex object modeling, rich relationships, the separation of logical and physical data abstractions, query rich data model concepts, active notifications, better integration with middle-tier infrastructure.
In particular, it is a common scenario to persist an object graph to a database (e.g., or more generally, any source of data such as a file). Furthermore, the object graph can be the primary means of manipulating data within that database. Since the object graph is not a direct view on the database but rather a cached view of the database, a buffer of changes to the object graph can be maintained. The buffer of changes to the object graph can either be flushed to the database or discarded. Such changes to the object graph can be further maintained by a context. Various and disparate sets of rules can be utilized by a context to handle such changes associated with a database. Yet, efficient and/or optimized rules to handle the context can be complex in light of the plurality of referencing within object graphs.